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REMARKS 
Status Summary 

Claims 1-78 are pending in the present application. Claims 1 1-21 , 51-60, 67, 68, 
77 and 78 have been withdrawn. Applicants acknowledge with appreciation the 
Examiner's indication that Claims 35-41 , 73 and 74 are allowed. 

Affirmation of Election 
Applicants affirm the election made by applicants' representative, Mr. Gregory A. 
Hunt on April 30, 2004 in electing the invention of Group I, Claims 1-10, 22-50, 61-66 
and 69-76. 

Claim Rejection - 35 U.S.C. § 103 

Claims 1, 4, 6, 10, 22-23, 25, 28-33, 42, 45-47, 61-65, 69, 71 and 75 stand 
rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 
6,718,178 to Sladek et al. ("Sladek") in view of U.S. Patent No. 6,611,516 to Pirkola et 
aL (" Pirkola "). This rejection is respectfully traversed. 

Independent claims 1, 5, 22, 29, and 42 recite methods, presence registration 
and routing nodes, and computer program products for deriving presence information 
from telephony related actions and forwarding the presence information to a presence 
server or presence server database. For example, independent claim 1 recites that 
SS7 message is received in response to a telephony related action. Next, it is 
determined whether presence registration processing is required for a target end user. 
In response to determining that presence registration is required, a presence 
registration message is generated. The presence registration message includes 
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presence information usable by a presence server for automatically indicating to the end 
users who are subscribed to the target end user in a presence database a presence 
status for the target end user. The presence registration message is then sent to a 
presence server. 

Two important features now claimed are the formation of a presence registration 
message based on a telephony related action and the communication of presence 
status information derived from the telephony related action to a presence database. 

Sladek relates to a method for automatically delivering SMS messages to the 
calling party (see, e.g., column 15, line 14 of Sladek ). the called party (see, e.g., column 
15, line 7 of Sladek ), or a third party (see, e.g., column 8, lines 39-52 of Sladek ). in 
response to a call processing event. There is absolutely no teaching or suggestion of 
generating presence status information based on a telephony-related action or of 
forwarding a presence registration message to a presence database, as claimed. 
Instead of generating presence information usable by a presence server to notify 
entities subscribed to a target subscriber a presence status of the target subscriber, 
Sladek teaches contacting an HLR to obtain subscriber location information. For 
example, Sladek states: 

In particular, CPE may be programmed to send an IS-41 SMS_Req 
message to the HLR of SME 24 (possibly via one or more other HLRs), 
and to receive a response SMS_Req message from the HLR, providing 
the SMS address of the SME 24 (assuming the destination SME is 
available). (See column 12, lines 24-29 of Sladek .) 

From this passage, Sladek teaches that the CPE queries an HLR to obtain the 
destination entity or SME location. Querying the HLR for each SMS delivery is 
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fundamentally different from generating presence information usable by a presence 
server for notifying subscribers of a target entity of the presence status of the target 
entity. An HLR is a mobile communications network entity that stores mobile 
subscription information. An HLR responds to queries from MSCs and is updated by 
messages from VLRs. HLRs do not store presence status, HLRs do not allow 
subscribers to subscribe to other subscribers, and HLRs do not communicate with end 
users. A presence server is an IP network entity that stores presence status, allows 
subscribers to subscribe to other subscribers, and communicates with end users. 
Moreover, there is no defined procedure for updating presence status regarding a target 
end user in a presence server as there is for updating subscriber location information in 
an HLR, not to mention updating presence status based on a telephony-related action. 
Thus, for these reasons, Sladek fails to teach the invention as claimed. 

In paragraph (c) on page 4, the Official Action indicates that Figure 9, reference 
42, reference 12, and column 15, lines 2-7 of Sladek disclose automatically generating 
presence information usable by a presence server for notifying subscribers of a target 
user of the presence status of the target user as claimed. Applicants respectfully 
disagree. As a preliminary matter, there is no reference numeral 42 in Figure 9 of 
Sladek . Assuming that reference numeral 42 in Figure 8 of Sladek was intended, this 
numeral indicates SMS logic in CCP 34 that performs the automatic SMS delivery 
mechanism described above. Reference numeral 12 of Sladek indicates a mobile 
handset. Column 15, lines 2-7 of Sladek describe automatic delivery of an SMS 
message to a called subscriber. None of these passages teach or even remotely 
suggest generating presence information as claimed. 
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Pirkola fails to teach the elements of claims 1, 5, 22, 29, and 42 missing from 
Sladek . Pirkola is directed to a system for maintaining updated status and location 
information in a subscriber's home function each time the subscriber changes locations. 
In Figure 2 of Pirkola . the home function 266 is simply the gateway MSC and the HLR 
264 of the subscriber. The subscriber terminal monitors one or more predetermined 
channels for broadcast information identifying a sub-network or a location area. Based 
on this information, a subscriber or the subscriber terminal can determine whether the 
subscriber has changed locations by comparing the subscriber's current location to his 
previous location. If the subscriber has changed locations, the subscriber is required to 
register with a new visited function at the new location. In Figure 2 of Pirkola . the visited 
function 274 is simply the VLR 270 and the MSC serving the subscriber. With regard to 
subscriber registration, Pirkola states that the visited function provides the subscriber's 
current location to the home function for the purpose of delivering calls to the 
subscriber. (See column 13, lines 1-21 of Pirkola ). From these passages. Pirkola . like 
Sladek . is directed to updating mobile subscriber location information in HLRs and VLRs 
and has nothing to do with updating presence information in a presence server. Thus, 
Pirkola . like Sladek. fails to teach or suggest generating presence information, 
generating a presence registration message, or forwarding the presence registration 
message to a presence server as claimed. Accordingly, because Sladek and Pirkola fail 
to teach the invention as claimed, it is respectfully submitted that the rejection of the 
claims based on Sladek in view of Pirkola should be withdrawn. 
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Claims 2, 3, 27, 43, and 44 were rejected under 35 U.S.C. § 103(a) as 
unpatentable over Sladek in view of Pirkola and further in view of U.S. Patent No. 
6,430,176 to Christie, IV (hereinafter, " Christie "). This rejection is respectfully traversed. 

As stated above, neither Sladek nor Pirkola teaches or suggests a method, a 
system, a presence registration and routing node, or a computer program product that 
automatically generates presence information based on a telephony-related action 
performed by a target subscriber and forwards the presence registration message to a 
presence server. Christie likewise lacks such teaching or suggestion. Christie is 
directed to a method for integrating high quality PSTN voice communications and data 
communications. According to Christie , ISUP messages are used in combination with 
H.323 messages to set up a voice call and a data call between end users. (See Figure 
3 of Christie .) There is absolutely no teaching or suggestion of automatically generating 
presence information or forwarding a presence registration message to a presence 
server as claimed in the independent claims of the present application. In addition, the 
fact that Christie discloses that the ISUP protocol is used to perform call setup does not 
render the obvious dependent claims that relate to using ISUP messages to trigger 
presence registration. As described above, Figure 3 of Christie simply discloses that the 
ISUP protocol is used to perform call setup, which is the normal function of the ISUP 
protocol. There is absolutely no teaching or suggestion of using any ISUP messages to 
trigger presence registration. Accordingly, for these reasons, it is respectfully submitted 
that the rejection of claims 2, 3, 27, 43, and 44 as unpatentable over Sladek in view of 
Pirkola and further in view of Christie should be withdrawn. 



-22- 



Serial No.: 09/627,253 

Claims 7-9, 24, 26, 34, 48-50, 66, 70, 72, and 76 were rejected under 35 U.S.C. 
§ 103(a) as unpatentable over Sladek in view of Pirkola and further in view of U.S. 
Patent No. 6,564,261 to Gudionsson et al. (hereinafter, " Gudionsson "). This rejection is 
respectfully traversed. 

As stated above with regard to the rejection of the independent claims, Sladek 
and Pirkola fail to teach automatically generating presence information based on a 
telephony-related action or transmitting a presence registration message including the 
presence information to a presence server. Gudionsson likewise lacks such teaching or 
suggestion. Gudionsson is directed to a communications network where a cluster of 
servers 1 allows users to set up multimedia communications with other users. The 
Official Action correctly notes that Gudjonsson discloses both session initiation protocol 
(SIP) messages and the instant messaging and presence protocol (IMPP). However, 
Gudionsson does nothing to connect these protocols as claimed in the claims of the 
present application. For example, claim 7 depends from claim 1 and recites that the IP 
message sent to the presence server is a SIP message. Thus, claim 7, when read with 
claim 1 recites generating a SIP message to update presence registration information 
based on an SS7 message. In contrast, Gudionsson recites only the conventional use 
of the SIP and IMPP protocols. For example, with regard to the SIP protocol, 
Gudionsson states: 

When a user 7 wishes to establish a communication with another user, 
he/she will invoke some function within his/her client 11, requesting the 
client to send an invitation of a given type to some selected user. The 
user client will then form the correct SIP message and send it to the 
special service within the cluster, called the routing service. (See column 
9, lines 13-19 of Gudionsson .) 
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From this passage, Gudionsson states that SIP is used to set up sessions between end 
users. This is the normal use of the SIP protocol. There is absolutely no teaching or 
suggestion of using SIP to perform a presence registration. 
With regard to the IMPP protocol, Gudionsson states: 

Various companies have created networks running on top of the Internet 
that allow users to send each other short text messages and monitor the 
status of other users, where the status is usually defined as whether a 
user is currently connected to a network or not. This kind of functionality 
is current being considered as the IETF standard called IMPP (instant 
messaging and presence protocol). (See column 2, lines 16-22 of 
Gudionsson .) 

The above quoted passage from Gudionsson merely states that the IMPP protocol is 
used to communicate status information regarding whether or not users are connected 
to a network. This is the normal use of the presence protocol. There is absolutely no 
teaching or suggestion of updating presence information using a SIP message, for 
example as claimed in claim 7 or of updating presence information to allow users to 
communicate with other users via an instant messaging protocol based on SS7 
messages, for example, as claimed in claim 66. Accordingly, it is respectfully submitted 
that the rejection of the claims that relate to SIP and instant messaging protocols as 
unpatentable over Sladek in view of Pirkola and further in view of Gudionsson should be 
withdrawn. 

Request for Telephone Examiner Interview 
Applicant's attorney, Gregory A. Hunt, respectfully requests a Telephone 
Examiner Interview when the Examiner considers this response. It is believed that a 
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Telephone Examiner Interview will expedite prosecution of the application. The 
Examiner can contact Applicant's attorney to schedule the Interview at (919) 493-8000. 



In light of the above amendments and remarks, it is respectfully submitted that 
the present application is now in proper condition for allowance, and an early notice to 
such effect is earnestly solicited. 

If any small matter should remain outstanding after the Patent Examiner has had 
an opportunity to review the above Remarks, the Patent Examiner is respectfully 
requested to telephone the undersigned patent attorney in order to resolve these 
matters and avoid the issuance of another Official Action. 



The Commissioner is hereby authorized to charge any fees associated with the 
filing of this correspondence to Deposit Account No. 50-0426 . 



CONCLUSION 



DEPOSIT ACCOUNT 



Respectfully submitted, 



JENKINS, WILSON & TAYLOR, P.A. 



Date: November 19. 2004 



By: 




Customer No. 25297 
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